我们的SaaS生意如何绕开定制化

前两周一个科技峰会上，主持人问明源云的创始人高宇：“关于软件绕不开的话题：中国企业怎么做SaaS？SaaS好像在中国特别难做，定制化怎么绕得开呢？”

高总回答得很诚恳，回顾了自己多年的创业历程，在曾经没有风险投资的时代，公司便已练就了持续的盈利能力和长跑能力。

而关于企业服务无法绕开的大客户的个性化需求/定制化，他提出的解决方案有两个重点：

1. 学习全球顶尖SaaS企业，例如Salesforce，以PaaS来满足客户个性化需求。

2. 要兼顾定制化和SaaS产品标准化。也就是说必须兼顾好SaaS持续进化迭代和客户的甚至是较大规模的定制化之间的矛盾，一方面可以迭代进化，一方面可以持续地进行个性化的定制服务。两边都要做好。

明源云的业务聚焦在地产行业，服务的都是收入规模在几十亿到上千亿的大客户。

“明源云由高宇等人于2003年11月创立，早期售楼软件是公司唯一的产品，2006年又推出了专门服务于地产开发商的ERP解决方案，帮助其管理业务流程。2014年，公司察觉到SaaS模式在满足地产产业链上各种多元化场景的优势，陆续推出了满足地产生态链上各种业务场景的SaaS产品「云采购」、「云客」、「云空间」和「云链」。”

因为明源云提供的ERP解决方案是深度参与到企业内部的业务流程，解决的是代表企业客户竞争价值的核心业务问题，而企业服务的生意但凡具有内部性的时候（我在《正确的非共识》里从生意模式的角度分析过生意的内部性和外部性），也就是说产品进入的是客户内部系统的时候，想做产品的标准化都非常难。

这源于不同企业内部的业务流程都有各自独特的属性，百花齐放，就如同家家户户的装修风格因各家的审美品味不同而都不尽相同是一个道理。

由此，业务的性质决定了明源云要全方位坚定不移转SaaS，只能沿着全球顶尖SaaS公司Salesforce的成功路径，为客户提供PaaS的解决方案，兼顾标准化和定制化的平衡。

从去年FY20明源云的财报中，我们也可以看到明源云的确平衡得挺好：

FY20明源云收入分成两个部分，大概各占半壁江山。SaaS产品营业收入8.71亿元，占比51.09%，ERP解决方案营业收入8.34亿元，占比48.91%。

同时，明源云SaaS收入占比也在逐年提升。FY21中报显示，明源云的SaaS收入占比从去年的51.09%提升至56.67%。

高总给到的经验之谈的确很适合他们所专注的行业与产品。

但如果跳离了行业，对其他公司在特定行业和产品上的真知灼见生搬硬套，未必对自己的业务有同样的帮助。

对我们业务而言，我们的主要客户群体也都是大中企业，且不限行业。但是对大客户定制化的需求，在我们自己一路摸索的过程中，得出的结论就是鱼和熊掌不可兼得。我们专注于产品的标准化。

我们可以从宏观与微观两个方面来看定制化需求这个问题。

01

「宏观角度」看定制化需求

首先从宏观层面而言，电子合同云平台的SaaS系统就应该不是定制化的，因为电子合同天然具有外部性。

这一点我们和明源云具有内部性的业务性质全然不同。

电子签约跟E-mail系统很像：

对于企业客户来说，都需要使用这个系统把一份文件或者材料，发送给另外一个企业。而与其他一些业务系统，如ERP、eHR、CRM等不同，这些可以归成“内部系统”。对于邮件系统，你会发现市面上其实没有多少邮件系统，而且每个厂商提供的邮件产品，都是类似的，可以说不存在“定制化”。

究其原因，核心还是因为邮件要互通。

虽然企业与企业各不相同，但如果要确保互通，只有双方保持一致，也就是说一样的东西才能互通。比如拔河，双方手里握着的都是一根同样的绳子；比如村村通的电话网、有线电视网、互联网，每个村加入的也都是同样的网；再比如让城市四通八达的高速公路，不同的城镇连接彼此的也是同样一条路。

简言之，但凡要互通，互通的这个媒介，就应该是非定制化的标品，否则就没有办法互通了。

电子合同也是这样的一款产品，跟邮件一样需要互通，那就注定了电子合同也必须要是标准化的，否则我发给你的合同，由于我是定制化的，你甚至可能都无法查看签署。

这也是为什么我们一直在强调，本地化部署的OP生意无法实现互连互通——不管是从底层逻辑上来看，还是在中国传统OP电子签章生意实践了20年，都证明了OP电子签章不可能实现互连互通。

随着电子签约的快速发展，OP的解决方案会让客户无法真正实现自由签署，这样的解决方案注定逐步被淘汰。并且，正因为OP不需要考虑互通，所以OP可以自由承接客户大量的定制化需求。

类比Zoom，我们应该可以更加直观地体会到这里面的差异。Zoom也是一款需要互通的软件，不同企业之间可以通过视频会议沟通，很难想象Zoom会给不同的企业提供定制化的功能，那样他们将无法进行会议。

当然，个别一两处细节上，会有不同程度的定制化，这是不可避免的。但总的来说，具有外部性的互通产品的设计整体逻辑是非定制化的，是标准的。

这其实是一个行业细分选择的问题。

要看着这家企业究竟是想做互通这部分广袤无垠的超大市场，还是想包揽延伸的细分市场。

还是拿Zoom举例子：

会议结束后，会上所达成的共识和行动计划都还需要去落实并追踪。这是紧跟着会议的一部分延伸领域。但我们很快就会发现，不同企业在这里就有分歧了，你用KPI，我用OKR，你有你的追踪方式，我有我的管理办法。假设Zoom要继续提供“会后行动”的功能，延展深入这部分市场，那么Zoom就要开始满足客户个性化需求，踏上定制化服务之旅。

回到电子签约领域，我们发现电子合同最根本的一点就是本身需要互通，所以构建互通网络是基础。同时类似于Zoom要不要去做“会后行动”的功能，在签署合同流程的前后，也有很多可延伸的领域可开发。

比如合同文本创建的时候，不同的法务需求，专业属性行业属性都非常强。

比如履约管理的时候，不同的公司、行业的履约需求，专业属性、行业属性同样也非常强。履约管理极为复杂的一个场景，例如制造业和融资租赁行业，是很不一样的履约，这其中还牵扯到信用管理、物料管理等中间环节，包括一个公司多样化的合同，内部也很不一样，真正实现合同的完成，在系统上去界定是一个很大的难题。这和Zoom会议后不同类型的管理风格是相似的。在签署完成后，合同的执行才刚开始。这类延展的领域里，只要去提供相应的功能，就一定会遇到定制化的问题。

但其实，上述的两个例子属于另外两个细分市场，有专门提供法律软件的厂商和传统合同管理的厂商。

而市场如何细分，是没有既定规则的。这和一家企业的战略、使命、愿景紧密相连。

企业可以选择紧盯着某个行业，做完整延伸全覆盖的市场，做大而全的生意。就像前述假设的Zoom先做视频会议，再去做“会后行动”等纵向深入功能的会议相关的全链路生意。

若拿我们的生意类比，就是做电子签约之外，还可以延伸去覆盖涉及较多定制化的合同法务生意及签署流程完成后的合同管理生意。

企业也可以去选择做互通最底层的这部分超大市场。就像我们通过电子合同实现企业和企业的互连，企业和个人的互连，个人与个人的互连。这是一个典型的无限风光在险峰的市场。路阻而长，行则将至。

前者的延伸全链路生意如同要请一位米其林星级厨师做独家创意私房菜，后者的底层织网战略可类比为去做有着标准化中央厨房的连锁餐厅，可以快速扩张，开遍全世界。

两者的选择方向截然不同，结出的果实必定相差甚远。

定制化有定制化的活法，OP传统软件公司和集成公司也能做成不小的生意规模；互通有互通的做法，互连互通互信SaaS面对的是一个前所未有、想象空间无限、迷人的、未来是星辰大海的超大市场。

这是不同生意的选择，而不仅仅是“是否定制化”的问题。因此本质上，这属于定义好自己的细分市场边界的问题。

02

「微观角度」看定制化需求

而在微观层面，具体某些功能的定制化，在这方面，其实只要是SaaS企业，相信大家都深有体会，随着客户的增长，需求的增多，一定会出现各式各样的个性化需求。

我们将从产品、项目交付和服务三个维度来看如何绕开定制化，专注标准化。

产品的标准化

在产品层面，解决的办法无外乎是尽量考虑全面，做到通用化，或者用升维的办法彻底解决产生需求的原始场景问题。

何为通用化？

指的是，面对一个客户的个性化需求，我们的产品会首先评估，是不是可以成为其他所有客户通用化需要的功能。如果是，这个需求我们便承接。这个承接其实并非在做纯粹项目制的定制化开发，而是在为标准化产品增加新的功能，因为新增的功能是可以复用在其他客户身上的。

所以在这个过程中就特别考验产品经理的能力，需要想办法提取和识别标准化需求。

那站在产品层面，我们先理解下什么是标准化（其实是提炼于普遍需求）：

确定一个行业领域的目标群体，当该群体想要达到一定的业务目标时，则会产生一些诉求。当这些诉求体现在一个产品层面的时候，就是我们产品所要关注的标准了。

这个背后体现了两点：

a. 客户业务的标准化

客户的业务本身是有一个标准化流程的，这个流程可能是公司内部的一个标准，或者是企业和企业之间的标准，这才意味着需求的稳定性。

倘若没有这种标准，就像价格随着价值上下波动一样，属于不稳定状态。所以这就是为什么我们做企业服务级B端产品，对产品经理的要求是真正懂得客户业务，能够深入客户行业，因为这样他更容易抓到一些产品上普遍与共性的因素。

b. 客户行业的标准化

公司和公司是不一样的，不同客户本身的职业习惯和公司的培训、管理制度也决定了企业对产品的信息化和数字化要求程度不一，这就意味着我们产品设计理念也随之不同。

在做一个行业的产品时，首先我们就想办法找到这个行业标准化的要素，但是这个过程依赖于要先找到这个行业里业务上的一个支撑点。在这个支撑点的基础上锁定一个有代表性的客户。

有代表性的客户并不意味着就一定是营收规模在行业最大，或者是logo最闪耀、公司最知名、品牌美誉度最高的那个，而是这个客户的产品诉求的的确确有着行业的共性。在做产品标准化当中，这样的客户才是产品团队的标杆客户，这和销售团队打单看客户的影响力做的关键节点客户分类是不一致的。

比如某行业排名第一的大客户很可能并不是产品团队做标准化的标杆客户，但是肯定会是我们销售团队的标杆客户。所以产品经理需要去分析客户诉求是不是在行业里的其他家企业也同样存在。

那产品凭借经验抽取出了普遍需求通过开发新的功能满足后，如何再去做闭环验证呢？

这里我们会快速在内部进行培训，在老客户上先行验证。其次在市场上，找到市场需求，看是否有能力打下这类有相关需求的客户，为其提供服务。我们可以看到，通过产品功能覆盖客户普适业务需求的覆盖率/覆盖情况就能体现产品经理做标准SaaS产品的视角、理念以及产品当前的标准化程度。

简言之，标准化就是要实现让这个产品在覆盖标准化业务需求的同时尽可能覆盖同类标准化的企业群体，我们也可以称之为“产品的覆盖面”。而覆盖面之外的客户就是我们选择当下不聚焦触碰的客户，比如执意要求OP的政务、医院生意等等。在战略取舍上，我们始终保持克制。

除去产品通用化，我们还可采用升维的解决方案彻底解决产生需求的原始场景问题。

升维可以理解为：比如客户提出我要一碗蛋炒饭，其实并非一定非蛋炒饭不可，客户只是饿了，需要食物果腹，随口说想吃蛋炒饭。那么我们提供现有的常德牛肉米粉、卤肉饭、乳酪饼、披萨、肉夹馍行不行？和客户沟通了解到客户真正的需求后，给客户提供可以填饱肚子的其他美味，往往也会欣然接受，甚至更喜欢。

所以产品经理要有能力透过问题洞察客户真正的需求。

总的来讲，大客户一定会不可避免的存在定制化的部分，毕竟不同公司的管理流程迥然不同。即便遇到类似的情况，我们也应该尽量去避免不必要的定制化。毕竟标准化是SaaS的灵魂所在，也是SaaS生意模式优势的重要体现。

众所周知，标准化具备优势的最大原因是：随着用户数的增加，先前投入的产研和交付成本将被无限摊薄，是典型的边际成本递减的生意。产研和交付的成本越低，产品利润率就越高，这也是相较于传统的B端定制交付和外包厂商，SaaS企业所具备“成本领先战略”的典型优势。

在我们的实际工作中，关于定制化也有一些体会。

其实很多定制化不是需求本身的原因导致的，而是一开始提供的产品方案考虑不全面、不彻底。给客户提供了第一阶段的功能，发现无法满足客户全部需求，只好不断地打补丁。这些补丁功能才是大量定制化的功能本身。所以当我们发现某一阶段功能做得不对的时候，应该重新全面考虑这个问题。

同时，之前做过的成功的功能，会导致下一个阶段的定制化。因为之前已有某些既定的功能，我们会不自觉地去引用这些功能来描述新遇到的需求场景，不自觉地会产生路径依赖，认为要从既有的功能出发，去解决客户的新需求场景，就会导致解决不到位，就又产生定制化的问题。

我们应该始终保证，能够从客户出发，理解场景，分析透彻，不可以去讲概念或者功能。

针对以上这些情况，我们会有相应的产品管理办法：

比如针对上述第一种情况，若是需要“精妙逻辑”（即在设计产品的时候有比较多的限制，需要满足a,b,c等多种条件，才能用起来），这样即便能解决客户当前的问题，但一定是不够好的设计才能解决的需求场景，我们认为这样的设计一定是不合理的，需要重新分析。 

针对上述第二种情况，我们规定在分析需求时，不可以引用自身已有的功能名词。并且，我们把这些规定落实到了标准的PRD写作模板，有详细的规定、说明，还会评审。

项目交付的标准化

交付层面的定制化的意义包含两种：

第一类：是除了以上产品层面能承接的需求外，必然还会存在被产品明确拒绝了或产品层无法解决的需求我们做不做？要不要扩大客户的定制化需求来增加人天以达到增加收入的目的？

第二类：与当前电子签约SaaS公司定位有较大偏离的总集或本地化项目做不做，到嘴的肉要不要拒绝？

首先，面对第一类情况，我们会去评估这类需求对项目交付是否非常关键。

举个例子：客户系统和我们的产品都是SaaS，需要通过一个中间件来实现数据的流转，面对此类的需求，我们是按如下条件去评估承接：

a. 是否为战略客户，并对客户核心签约业务使用造成决定性影响；

b. 项目交付边界是否与签约业务有关；

c. 定制化开发的功能具备未来可产品通用化的可能或具备一定的战略探索性。

满足上述全部条件的需求项我们才会考虑，所以此类需求经过层层漏斗后真正被承接的实际上极少。同时我们严格控制和简化定制化部分的边界和方案，在这样的单项目里的定制化开发部分会严格控制量。

这里举个客户案例：

某零售行业世界500强跨国公司客户在招标文件中提出明确的要求：需要做个中间件，并为此支付12万的定制开发人天。待我们PM入场对实地业务和系统进行详尽地调研后，建议客户可以用其他简便的替代方法达到该中间件可实现的业务目标，客户认可了这种高效又“省钱”的方式（即文章中产品标准化段落里提到的升维的解决方案）。同时后期客户也变更了商务合同，欣然把这一次性的12万人工开发费转化成了合同份数的订阅式收入。

面对第二类总集项目和OP项目，从成立的第一天起，我们就是明确拒绝的。

记得公司早期，我们南区销售团队曾经打下过两家知名头部客户，分别来自地产行业和制造业，客单价均超过了300万。这样的客单价，对于电子签约SaaS公司而言，实属惊人的高价，诱人的大肥肉。

因为两个项目都是典型的OP项目，需要大量定制化，可以说就是外包项目，所以才会有如此高的客单价。项目最后申报到我这里特批，任由销售如何解释，我坚持不批这两个项目。辛苦打下项目的销售团队分外委屈。当时我的合伙人（现已离职4年）也因此和我大吵一架。他指责我的理由是：作为一家创业公司，我们没有资格选客户。到手的钱不赚而拱手相让给同行，这是CEO一言堂、固执不听一线的声音，是CEO的失职，也是战略失误。

我当时和大家表达的观点和现在的认知依然一致：这样没有战略意义的传统软件项目，接得越多，亏得越多，离我们的战略目标越遥远，因此任何时候我们都不应该分散兵力接这样无战略价值并且仅仅是看上去有高收入实际低毛利的传统项目。选择比努力更重要。在战略方向正确的前提下，组织能力和执行力才会卓有成效。

当时的合伙人因此想不通，找到我的mentor表达不理解与愤懑。

我的mentor对我们非常尽心，来了一趟杭州和我们开会。mentor支持我的选择，也给到了我们许多宝贵的建议。记得他对我当时的合伙人讲，如果将军下令攻打一个山头，不管你是否认同，军人的天职都无条件要往前冲，而不是打仗的时候在主帅明确下命令之后，还在质疑，而不去攻打山头，这样只会贻误战机。

从成立至今，我们一直定位清晰，知道什么是我们要去做的，什么是我们不触碰的。

我们可以看到，标准化不仅仅指产品层面，是产品从设计到交付层层需要去坚持的。同时，建立在产品的标准化基础上，才能带来标准化的交付。

以上的坚持的确很难，也曾在早期伴随着很多质疑与压力，但是如今坚持下来后的好处也是显而易见的。

我们的产品标准化、交付轻，在市面上是SaaS产品中交付周期最短的一类，可以帮助客户实现快速地上线和业务目标的达成。例如：我们1个技术支持平均可在一年内完成30-40个客户的交付，总共才10人的PMO团队可以支持一年100多个头部大客户的上线。

所以，在清晰和正确的SaaS战略下做选择，我们严苛控制定制化的边界。因为是否能实现定制化需求并不是技术问题，而是企业战略选择和在面对具体问题时真正做出选择的问题。

服务的标准化 

服务的标准化，毫无疑问建立在产品标准化和交付标准化的基础之上。如果产品定制化，项目定制化，服务则无法标准化。

SaaS企业如果前期没有打好标准化的基底，后期随着客户数量和规模的增长，势必技术人员人数会随着客户数呈现正相关的增长。如果人数增长无法保证，则会大大降低客户的服务标准。

我们在行业内的服务口碑是获得客户认可与称赞的，这得益于我们始终坚持标准化。因为是标准化产品，所以我们公司内部人员和客户的使用者所看到的是同一套产品，类似于两人同时在Zoom会议上文件共享，看到的是同一份文件。因此当客户咨询使用问题的时候，即便是我们轻量化配置的客服和客户成功都能快速定位并解答。所以我们常常因为高效而受到客户好评。

而本地化、定制化带来的客户体验与相关服务都远不如标准化，则是因为本地化、定制化如果要保证服务质量就需要投入大量的服务成本。本地化的产品，厂商无法看到客户的生产环境，所以出现问题时无法定位问题，更是难以迅速解决，会较长时间影响客户正常经营，引起客户不满；定制化则是卖人天、堆人头的低毛利项目，需要厂商投入大量人力成本。

我们确实因为坚持SaaS以及严苛控制定制化，所以拒掉过一些客户的需求，这就倒逼我们产品团队必须识别出高ROI的客户需求，不断提升自己的产品力，这样就形成一种正向的循环反馈机制：

坚持SaaS/严控定制化/定义电子签约产品的边界→识别高ROI功能→产品满足大部分客户的核心和普适性需求。

这就是为什么上上签的SaaS产品可以不通过大量定制化依旧可以满足当前大部分的大客户核心业务需求。同时，面对大型企业的个性化，可以在我们的标准上提供更多的开放性和能力，让第三方更好地面向客户形成生态效应。

SaaS的标准化，其实对客户而言价值是更大的。对于个性化，你的需求只是你的，但更多企业的需求被标准化在产品里后，你应用的产品就是集众家之所长，是更有生命力的。

SaaS的标准化并不难，不是水中花、镜中月与空中楼阁。倘若要驶向SaaS的标准化，需要结合企业具体所在的赛道特质以及公司长期发展战略目标去做选择。

最终我们选择的路是由得失的经纬所构成。前瞻性地思考清楚可能的所失所得，企业日常经营的抉择就会变得清晰且简单。

更多文章：